Architecture-based software reengineering

views Basic views Parser Analyser View processing View builder Abstract program representation Figure 1 Basic reverse-engineering framework The first step is to transform the system’s artifacts (primarily the source code, but also the file structure, directory structure, build and make files) to some abstract representation from which further manipulation could be performed. The result of this computation is stored in some kind of permanent repository. This step has two main advantages • To facilitate the subsequent processing of the different information sources which are transformed into one single formalism; • To eliminate the peculiarities of the source’s programming language. However this is true only to a certain extent. In fact, when the programming paradigm changes (generally from a procedural style to an object-oriented one) then, to some extent, it must be reflected in the abstract representation (unless the parser/analyzer makes some paradigm transformation). It must be noted that the abstract representation is basically at the same level of abstraction as the original artifact, although some information could have been filtered out (noise reduction). Among the abstract representations one finds all graph-related data structures, partition relation algebra [Kri99], or proprietary formalisms like the famous Rigi Standard Format (RSF): the input format to the well known Rigi reverse-engineering tool ([Mul93], [Won98]) or the FAMIX format of the FAMOOS ESPRIT Project [Dem99]. The second step (view builder) “processes” the information from the abstract representation repository to build the “views” of the system. These views represent some higher-level abstraction of the information. Usually, a single view does not provide enough clues to understand the system. The third step, the views processing, builds some meaningful human understandable abstracted view of the system by aggregating the information from multiple basic views. For example, the third step may abstract some higher representation of the architecture of the system or alternatively compute software metrics over the system. The result is often displayed as some form of graph structure, but not always. As an example, the CodeCrawler system [Lan03] builds a graphical representation that blends structural information and metrics. © Copyright Philippe Dugerdil, Haute école de gestion de Genève (Univ. of Applied Sciences), 7 rte de Drize, CH-1227 Geneva, Switzerland. [email protected] +41 22 388 17 00 www.hesge.ch/heg 7 1.3 Reverse engineering legacy systems Given a legacy system to reengineer, different information sources could be tapped to reverse-engineer it, among which we find: • The technical documentation of the system (specification, analysis, design, implementation, test, deployment documentation); • The manuals: the user and training manuals; • The expertise of the people involved in the development of the system and its maintenance: software architect, designer, developer and maintainer; • The deployment artifact of the system itself: source code with comments, directory and file structure, deployment descriptors, build and compilation scripts; The other stakeholders of the system: the users and business experts. According to Kruchten’s ideas [Kru95], a software architecture may be represented through 4+1 views, which give 4 different “perspectives” on a software system (the fifth is the “usecase” view that influences the 4 other views. Then, in the reverse-engineering context, a source of information could be characterized by 4 attributes: • abstraction level; • scope ; • truthfulness ; • associated views. As the views of a system are correlated, missing or uncertain information in some view might be reconstructed or strengthened using the information of another view. In fact every source of information may only describe some limited part of the system and/or not be up to date. Moreover, the attributes of a “human” source of information may not be known to the source itself (for example, a developer may not know that the system has evolved since its initial development). System artifacts Parser Analyzer Additional information © Copyright Philippe Dugerdil, Haute école de gestion de Genève (Univ. of Applied Sciences), 7 rte de Drize, CH-1227 Geneva, Switzerland. [email protected] +41 22 388 17 00 www.hesge.ch/heg 8 Figure 2 Basic reverse-engineering framework augmented with other information sources 5 The 4+1 view of software architecture is now integrated in the popular Rational Unified Process (RUP) for software development [Kru00]. The idea of software views is not unique to Kruchten’s work. For example it is also present in the work of Hofmeister et al [Hof00]. Although not similar, the views of Hofmeister are close to those of Kruchten. 6 The degree of coverage of the system by the information source. Additional information Abstract views Basic views View processing Abstract program representation View builderviews Basic views View processing Abstract program representation View builder